Definition and Application of Metaclasses in an Object-Oriented Database Model

CLASS Meta Objects; ATTR Token : STRING; FREE CLASS Classes SPEC Meta Objects; ATTR Number of Attributes : INTEGER; ATTR Attr : SET OF Attributes; ATTR Methods : SET OF Method; Method : TUPLE OF (. . . ); FREE CLASS Abstract Classes SPEC Classes; FREE CLASS Free Classes SPEC Classes; ATTR Spec Classes : SET OF Classes; FREE CLASS Attributes SPEC Meta Objects; FREE CLASS Tuple Attributes SPEC Attributes;. . . FREE CLASS Set Attributes SPEC Attributes;.. . Figure 5: System View tion system will be a graphics system. A new class Graphic Classes is introduced as a specialization of the class Classes of the system view. The type of this new class is, e.g., de ned by the name of the Designer and a set of Default Values for the attributes. Each fundamental object type prede ned in the graphics system is represented by a class which is a specialization of this class Graphic Classes. Elements of these classes are the fundamental object type itself and all specializations of it, its subtypes. Because all subtypes inherit not only the attributes, but all functions dened for the fundamental object type, these functions occur as attributes of the meta level classes. In the following, some of the classes of this view on the meta scheme are shown. FREE CLASS Graphic Classes SPEC Classes; ATTR Default Values : TUPLE OF (. . . ); Designer : STRING; FREE CLASS Point Classes SPEC Graphic Classes; FREE CLASS Vector Classes SPEC Graphic Classes; In contrast to the system view, the application view needs to be changeable. Every time a user de nes a new graphic object type that is not a subtype of any other type, a new metaclass in this application view is created. For example, Polygons is a userde ned object type which is not a subtype of any prede ned graphic type. By de ning a new object type as a subtype of an existing one, only a new object of the metaclass corresponding to the supertype is created and inserted. In our example, Squares is such a user-de ned subtype of the system-de ned object type Rectangles. In general, every metaclass in the application view is a (direct or indirect) specialization of the class Graphic Classes. Example 6 In the running example, the following classes in the application view are created: FREE CLASS Rectangle Classes SPEC Graphic Classes; FREE CLASS Polygon Classes SPEC Graphic Classes; Meta Objects Token 1 Points 2 Vectors 3 Polygons 4 Rectangles 5 Squares 6 Point Classes 7 Vector Classes 8 Polygon Classes 9 Rectangle Classes Graphic Classes Default Values Designer Parameter Def Value 1 Xco 0 Miller Yco 0 . . . Figure 6: Instances of the system view class Meta Objects and the application view class Graphic Classes Instances of some classes in the system and application view are given in Figure 6 and 7. 2 The complete de nition of the meta level including the possible update operations is given in [GH92]. 5 Special Meta Level Concepts In this subsection, we deal with more speci c issues concerning the meta level: the representation of methods, and the query operations on scheme and meta level. 5.1 Representation of methods. Interfaces and implementations of methods have to be represented at the meta level. While the description of the interface is similar to the representation of attributes for classes, the structure of the implementation part is more di cult. In other systems storing functions within a database, implementations are stored in attributes of type STRING (or long string). The problem with this approach is that the standard methods de ned for strings are not useful to support queries against method implementations. Additionally, an arbitrary modi cation of this string can result in an incorrect method implementation. A more structured representation of a method implementation is to de ne a parse tree as an ADT. This is the representation used in the OSCAR system. The ADT \parse tree" is implemented in the followingway: starting with the root of the parse tree, the descendants of this node are modelled as a list of nodes which can recursively be roots of subtrees. Since method implementations are given in a C++-like syntax, embedding the query and update operations of the OSCAR system, the nodes of the parse tree represent C++-, query or update expressions, respectively. Example 7 In the running example possible implementations of the method Rotate de ned on Rectangles and Squares are the following ones (together with their interfaces): Classes No fAttrgfMethodsgAttr AttrMethodName TypefParametersgQ/U ImplementationParameter121move BOOLEAN MX. . . U12MY223move BOOLEAN MX. . . U24MYlength REAL. . . Q3315436rotate BOOLEANU47850rotate BOOLEANU5Figure 7: Instance of the system view class ClassesUPDATE METHOD Rotate (): BOOLEAN;MODIFIES P, Heigth, Width; i, j, k, l: REALfi = Heigth; j = Width;k = (i-j)/2; l = j+k;P.Move (l,k); Heigth = j; Width = igUPDATE METHOD Rotate (): BOOLEAN;MODIFIES P USES Width; f P.Move (0,Width);gEach of these implementations (i.e., the f g-block) isrepresented by an ADT instance. For example, theimplementation ofRotate is described by a single nodeof type \C++-expression" in the parse tree.2The complete ADT de nition for the representationof methods including the representation of query lan-guage expressions is given in the long version of thispaper [GH92].5.2 Operations on scheme and meta level.Attached to the classes and types in EXTREM, OS-CAR provides a set of generic operations (as men-tioned in Subsection 3.2). These algebraic operationsare the basis for other query languages in OSCAR,e.g., a rule-based query language [HS91b]. If schemeand meta level are viewed separately, one can expressqueries in the same style as in the relational model| with di erent semantics due to the di erent datamodel. There are only some recent approaches to com-bine information of both levels within a single query[AB91]. In OSCAR, we simply use the EXTEND op-erator of the algebra which extends the state typeof an object set by information calculated with ar-bitrary methods. Two prede ned methods Metaclassand Metaclass* are necessary for retrieving informa-tion about the meta level and attaching it to schemelevel objects:(i) The prede ned methodMetaclass is attached to theclass Classes, so it can be used for any of the classesat the scheme level. The result of Metaclass appliedto a class C is a new tuple-valued attribute consistingof all the attributes and attribute values of the mostspecial metaclass C is an instance of.(ii) Metaclass* extends Metaclass by adding the at-tributes and attribute values of all the other meta-classes including C as an instance.The implementation of both methods is realized by aquery at the meta level, using our rule-based querylanguage LIVING IN A LATTICE [HS91b] (we needrecursion in collecting all the meta information avail-able for a scheme level class). Details of this imple-mentation are given in [GH92].Example 8 If we want to know the Designer and theset of Methods for the class Rectangles, we extendthe state type of Rectangles by Metaclass* with allthe meta information available for this class. In thefollowing query expression, the name of this new, cal-culated attribute is MI.PROJ[DESIGNER, METHODS] (EXTEND[MIRectangles.Metaclass*](Rectangles))In the projection list (or also the selection condition),we could add attributes of the class Rectangles besidesthe meta attributes calculated by Metaclass*. 2While our approach is to use the object algebra andadditional methods for operations at the scheme andmeta level, other approaches introduce special opera-tors for each purpose. For example, in Codd's RM/T-model [Cod79] three name operators, six set operatorsand three graph operators are additionally introduced.With our technique, we can represent all these opera-tors (except the APPLY operator of RM/T) by objectalgebra expressions at di erent levels. APPLY is usedto apply one query expression to each class of a set ofclasses. Since this operator seems to be important inaddition to the representable ones, we will add this op-erator to our object algebra in a forthcoming versionsimilar to the APPLY used in [TS92].5.3 Exceptions and defaults.We are able to de ne static attribute values, excep-tions and defaults at the meta level. For example, fordefaults we de ne the attribute at the scheme leveland store a default value at the meta level. Thedefault values can be represented in the metaclassGraphic Classes. If the user creates a new object ofthe class Points, the default value is 0 for each of thecoordinates. By modifying these values after creationof the object, the user can override them. 6 Conclusion and Further ResearchIn this paper, we presented a new approach to struc-ture meta information in an object-oriented databasesystem. We decided to split the meta level of our sys-tem OSCAR into two views: the system view is totallymaintained and controlled by the database system, theapplication view adds the meta information about aspecial application system or user. We presented theintegration of method implementations as meta infor-mation and the querying facilities combiningmeta andscheme level.There are some open problems to be solved. One prob-lem is the extension of the query algebra by new op-erators like APPLY which give more exibility to thequery language but also problems with the static typechecking of queries.References[AB91]R. Ahad and A. Basu. Esql : A query languagefor the relation model supporting image domains.In Proc. of the 7th IEEE Int. Conf. on Data Engi-neering, pages 550{559, 1991.[ABD+89] M. Atkinson, F. Bancilhon, D. DeWitt, K. Dit-trich, D. Maier, and S. Zdonik. The object-orienteddatabase system Manifesto. In [KNN89], pages 40{57, 1989.[AFS89] S. Abiteboul, P.C. Fischer, and H.-J. Schek, ed-itors. Nested Relations and Complex Objects inDatabases, volume 361 of LNCS. Springer, Berlin,1989.[BCG+87] J. Banerjee, H.-T. Chou, J.F. Garza, W. Kim,D. Woelk, N. Ballou, and H.-J. Kim. Data modelissues for object-oriented applications. ACM TOIS,5(1), 1987.[Bee89] C. Beeri. Formal models for object-orienteddatabases. In [KNN89], pages 370{395, 1989.[Bee90] C. Beeri. A formal approach to object-orienteddatabases. Data and Knowledge Engineering,5(4):353{382, 1990.[Cod79] E.F. Codd. Extending the database relationalmodel to capture more meaning. ACM TODS,4(4):397{434, 1979.[Deu90] O. Deux. The story of O2. IEEE TKDE, 2(1):91{108, 1990.[EGH92] K. Ecker, J. Goers, and R. Hirschberg. CHARM II| an alternative approach for geometric modeling.In F.-L. Krause, D. Ruland, and H. Jansen, edi-tors, Informatik aktuell: CAD '92, pages 434{441,Berlin, 1992. Springer.[GE90] J. Goers and K. Ecker. A CHARMing method formodeling graphical objects with EXTREMe objectbase support. In K. Dittrich and H. Thoma, edi-tors, Proc. Workshop Perspektiven der Datenbank-technik. SI, October 1990.[GH92] J. Goers and A. Heuer. De nition and applicationofmetaclasses in an object-oriented database model.Informatik-Bericht, TU Clausthal, 1992. In prepa-ration.[GR83] A. Goldberg and D. Robson. SMALLTALK-80 -The Language and its Implementation. Addison-Wesley, Reading, Massachusetts, 1983.[Heu89] A. Heuer. A data model for complex objects basedon a semantic database model and nested relations.In [AFS89], pages 297{312, 1989.[HFW90] A. Heuer, J. Fuchs, and U. Wiebking. OSCAR:An object-oriented database system with a nestedrelational kernel. In Proc. of the 9th Int. Conf. onER Approach, Lausanne, pages 95{110. Elsevier,October 1990.[HH91] C. Horner and A. Heuer. EXTREM | The struc-tural part of an object-oriented database model.Informatik-Bericht 91/5, TU Clausthal, October1991.[HHRW92] A. Heuer, C. Horner, H. Riedel, and U. Wiebking.Syntax, semantics, and evaluation of the EXTREMobject algebra. Informatik-Bericht, TU Clausthal,1992. In preparation.[HM81] M.M. Hammer and D.J. McLeod. Database descrip-tion with SDM: A semantic database model. ACMTODS, 6(3):351{386, 1981.[HS91a] A. Heuer and P. Sander. Classifying object-orientedquery results in a class/type lattice. In Proc. of the3rd Symposium MFDBS 91, volume 495 of LNCS,pages 14{28. Springer, May 1991.[HS91b] A. Heuer and P. Sander. Preserving and generat-ing objects in the LIVING IN THE LATTICE rulelanguage. In Proc. of the Int. IEEE Conf. on DataEngineering, Kobe, volume 7, pages 562{569, April1991.[HZ88]S. Heiler and S.B. Zdonik. FUGUE: a model forengineering information systems and other baroqueapplications. In C.Beeri, editor, Proc. of the 3rdInt. Conf. on Data and Knowledge Engineering,pages 195{210, 1988.[KA90] S. Khosha an and R. Abnous. Object Orientation.Wiley, New York, 1990.[Kla90] W. Klas. A Metaclass System for Open Object-Oriented Data Models. PhD thesis, TU Wien, 1990.[KNN89] W. Kim, J.-M. Nicolas, and S. Nishio, editors. Proc.1st Int. Conf. on Deductive and Object-OrientedDatabases, Kyoto. Elsevier, December 1989.[MBW80] J. Mylopoulos, P.A. Bernstein, and H.K.T. Wong.A language facility for designing database-intensiveapplications. ACM TODS, 5(2):185{207, 1980.Also in [ZM90].[Nix84] B. Nixon. TAXIS 84: Selected papers. TechnicalReport CSRG{160, University of Toronto, 1984.[Ont92] Ontos Inc. Ontos 2.1 SQL Guide, 1992.[Ser90]Servio Logic Development Corporation. GemStoneV 2.0: Programming in OPAL, 1990.[TS92]M. Tresch and M.H. Scholl. Meta object manage-ment and its application to database evolution. In-ternal report, University of Ulm, Department ofComputer Science, 1992. Submitted for publica-tion.[ZM90] S.B. Zdonik and D. Maier, editors. Readings inObject-Oriented Database Systems. Morgan Kauf-mann, San Mateo, CA, 1990.